Making Remote Procedure Calls

At times a preemptive task may need to call a system software function, and doing so may cause problems. For example, many calls to Mac OS system software manipulate global variables, so data could easily be corrupted if more than one task attempts to make similar calls. To work around this problem, Multiprocessing Services allows you to make remote procedure calls if you need to call system software from a preemptive task. A remote procedure call also allows your task to call 68K code.

IMPORTANT

With the exception of functions in Multiprocessing Services, you cannot safely call Mac OS system software functions directly from a preemptive task. Even if some system software function appears to work today when called from a preemptive task, unless explicitly stated otherwise there is no guarantee that subsequent versions of the same routine will continue to work in future versions of system software. In Mac OS 8 implementations of Multiprocessing Services, the only exceptions to this rule are the atomic memory operations (such as AddAtomic ) exported in the InterfaceLib shared library. Even these functions may switch to 68K mode if the operands to them are not properly aligned. If you need to access system software from a preemptive task, you must do so using the MPRemoteCall function.

To make a remote procedure call, you must designate an application-defined function that will make the actual calls to system software. You then pass a pointer to this function as well as any required parameters in the MPRemoteCall function.

Note

Since your application-defined function must be written in PowerPC code, you do not need to build a universal procedure pointer to pass to the MPRemoteCall function.

When you call the function MPRemoteCall from a task, that task is blocked, and the application-defined function you designated then executes as a cooperatively scheduled task, which can make system software calls with no danger.

Note that when you call MPRemoteCall , you can designate which context (or process) you want your application-defined function to execute in. If you specify that the function should execute in the same context that owns the task, the function has access to data available to the main application (just as if the application had called the function). However, the function cannot execute until the owning context becomes active (and then not until the application calls WaitNextEvent ). Alternatively, you can designate that the function execute in any available context. Doing so minimizes possible lag time, but the function cannot access any resources specific to the task's context.

IMPORTANT

In the future, individual application processes may not always share the same address space, so in general you should never attempt to access code or data in another process.

After your application-defined function returns, the task is unblocked and execution proceeds normally.